在今天的內容開始前複習一下在第11天提到的相關情境,對應這幾天介紹的Jira各項功能的解決方案。
上面的步驟完成後如果想要看到報表的資訊就選取需要看到的篩選條件,接著點擊新增訂閱後彈出來的視窗,設定需要收到的時間點後就完成訂閱的動作。
以下這個就是剛剛上面提到的訂閱功能,在固定時間寄送到指定的信箱就可以滿足報表回顧的需求囉。
然後下圖就是驗證的類型清單,從最客製的script到內建的功能都可以依照當前的需求設計,就可以達到驗證的機制。
過往沒有相關性質的系統可以參考
=> 在時程的壓力下從頭造輪子並且又比較偏向個人開發下,還是建議選擇適合的工具並且搭配可以純程式方式滿足較客製化的需求。(但如果專案時程較長並且是較成熟的團隊開發模式,反而是純程式開發可以做為首選)
有時程上的壓力並且希望能夠整合現有的相關登入機制(ex : 透過已經開好的OA帳號登入)
部分填寫人員已經熟悉現有的流程,如果系統做大幅度的改版對於他們而言較耗費時間學習
期望能夠透過一個平台延伸管理未來相同性質的需求
=> 上面三項前幾天有提到,第一點與第三點可以透過Jira的內建功能做相關的設定,而第二點會比較偏向是知識管理的部分,這時候就可以搭配Confluence來做深度整合的應用。
Confluence要建立新的空間時可以選取需要的範本,並且在建立完成後就可以透過範本的架構新增想要的內容。
接著新增一個畫面後透過快捷鍵尋找跟Jira相關的元件,選擇第一個後可以看到篩選條件的欄位(可以參考Jira篩選功能的JQL功能)。
輸入對應條件式之後就可以從Confluence看到Jira的相關Task。
總結Case 2的開發過程,透過這樣的方式除了檢視想要看到的填寫資訊外,同時延伸應用將Jira的相關教學以及這個系統的教學文件整合在Confluence內,長期而言若使用者未來會需要一個地方做內容上的更新,或者是要依照需要檢視的狀態做共同編輯的動作時,這樣的組合方案是一個很好的搭配。